Skip to content

Ensure that ./x.py doc --stage 0 src/libstd works via CI #71649

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
May 7, 2020
Merged

Ensure that ./x.py doc --stage 0 src/libstd works via CI #71649

merged 1 commit into from
May 7, 2020

Conversation

ecstatic-morse
Copy link
Contributor

@ecstatic-morse ecstatic-morse commented Apr 28, 2020 •
edited
Loading

This was split off from #71645, which recommends that users first try building libstd docs with the bootstrap rustdoc. This should work in most cases, but will fail if we start using a very recent rustdoc feature outside a #[cfg(not(bootstrap))].

It would be very nice to guarantee that ./x.py doc --stage 0 src/libstd works, since it allows documentation changes to be rendered locally without needing to build the compiler. However, it may put too big a burden on rustdoc developers who presumably want to dogfood new features.

@rust-highfive
Copy link
Contributor

r? @pietroalbini

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 28, 2020
@ecstatic-morse
Copy link
Contributor Author

cc @rust-lang/rustdoc

@ecstatic-morse
Copy link
Contributor Author

r? @GuillaumeGomez

@Mark-Simulacrum
Copy link
Member

To be clear from a "implementation" perspective this looks good to me, but I agree it would be good to get rustdoc sign off as the team that's closest to docs today... basically, I think this means "new shiny features" would be less easy to use in std's docs, unless they're e.g. top-level attributes that can easily be cfg'd away.

@Mark-Simulacrum Mark-Simulacrum mentioned this pull request May 3, 2020
Merged
@Mark-Simulacrum
Copy link
Member

I'm going to go ahead and approve this, but if we run into trouble due to it and there's no nice fixes I would be open to reverting.

@bors r+

@bors
Copy link
Collaborator

bors commented May 3, 2020

📌 Commit 1f7c896 has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 3, 2020
@bors
Copy link
Collaborator

bors commented May 4, 2020

⌛ Testing commit 1f7c896 with merge d88c74853164295717ffef1f8dc80efc39a63788...

@bors
Copy link
Collaborator

bors commented May 4, 2020

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 4, 2020
@ecstatic-morse
Copy link
Contributor Author

Seemingly unrelated failure upon invoking the linker on MacOS: nul byte found in provided data. That's...weird. Doesn't seem like your typical spurious error to me. WDYT @Mark-Simulacrum?

https://dev.azure.com/rust-lang/rust/_build/results?buildId=28262&view=logs&j=1c64c3ff-4c37-56fe-a133-b407354bbfbf&t=07a412a6-d5a9-54c7-0ba5-234866c24f9d&l=29278

@Mark-Simulacrum
Copy link
Member

Perhaps a race condition? Doesn't seem like it should/can be related to this PR though so let's @bors try

macOS linkers in general are pretty questionable so I wouldn't put it past this being spurious as well

@bors
Copy link
Collaborator

bors commented May 4, 2020

⌛ Trying commit 1f7c896 with merge 5d3f35f32f98377da91122864f55ad3a2607d09f...

@bors
Copy link
Collaborator

bors commented May 4, 2020

☀️ Try build successful - checks-azure
Build commit: 5d3f35f32f98377da91122864f55ad3a2607d09f (5d3f35f32f98377da91122864f55ad3a2607d09f)

@Mark-Simulacrum
Copy link
Member

What I meant was @bors retry

@bors
Copy link
Collaborator

bors commented May 4, 2020

⌛ Trying commit 1f7c896 with merge 95d1050f4d7ae3b8fca4736c31b7afb598ca3032...

@Mark-Simulacrum
Copy link
Member

@bors retry- r+

@ecstatic-morse
Copy link
Contributor Author

@bors try-

@ecstatic-morse
Copy link
Contributor Author

ecstatic-morse commented May 4, 2020 •
edited
Loading

For some reason, the "try" build is still pending in the queue but is no longer marked as a "try" build after I did try-. I don't think retry- is a command.
@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 4, 2020
@Mark-Simulacrum
Copy link
Member

@bors r- retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 4, 2020
@Mark-Simulacrum
Copy link
Member

@bors r+

Okay, I think this should do the trick...

@bors
Copy link
Collaborator

bors commented May 4, 2020

📌 Commit 1f7c896 has been approved by Mark-Simulacrum

@RalfJung
Copy link
Member

RalfJung commented May 5, 2020

Will this help ensure that ./x.py test src/libstd --stage 0 --doc works? This failed until the last bootstrap bump (#70770).

@Mark-Simulacrum
Copy link
Member

Hm, yes, it should help I think -- may not be a 100% fix for that command though as internally the plumbing of arguments is a little different between doc and test IIRC

@bors
Copy link
Collaborator

bors commented May 7, 2020

⌛ Testing commit 1f7c896 with merge 4802f09...

@bors
Copy link
Collaborator

bors commented May 7, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: Mark-Simulacrum
Pushing 4802f09 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 7, 2020
@bors bors merged commit 4802f09 into rust-lang:master May 7, 2020
@poliorcetics poliorcetics mentioned this pull request Aug 11, 2020
Merged
@ecstatic-morse ecstatic-morse deleted the ci-stage0-doc branch October 6, 2020 01:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@GuillaumeGomez GuillaumeGomez

Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
7 participants
@ecstatic-morse @rust-highfive @Mark-Simulacrum @bors @RalfJung @pietroalbini @GuillaumeGomez